home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group95b.txt
/
000052_icon-group-sender _Sun Jun 18 18:11:42 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-09-18
|
3KB
Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:03:03 MST
To: icon-group@cs.arizona.edu
Date: Sun, 18 Jun 1995 18:11:42 GMT
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Message-Id: <DADrvI.MrJ@midway.uchicago.edu>
Organization: The University of Chicago
Sender: icon-group-request@cs.arizona.edu
References: <1995Jun16.172604.22642@leeds.ac.uk>, <1995Jun17.174319.29735@nmt.edu>, <3s1fij$7r9@pipe.pipex.net>
Reply-To: goer@midway.uchicago.edu
Subject: Re: Perl v. Icon
Errors-To: icon-group-errors@cs.arizona.edu
In article <3s1fij$7r9@pipe.pipex.net>, Ian Phillipps <ian@pipex.net>
wrote:
>
>With Perl 4 and earlier, the weak point was, as John implies, data
>structures, although the split and join operators provided quite
>convenient workarounds.
Really, there's no question that Perl has much, much better integra-
tion with the OS then Icon. And interfaces exist between it and all
the major databases, etc. Perl is also being very actively worked on.
As far as I know, development work on Icon has officially ceased, and
all we will see are, perhaps, a few additional ports. Refinements to
the windowing system will probably go on for a few years, too.
>PPP Regular expressions. This is the biggie as far as I'm concerned.
> The sort of job where you're trying to parse incoming data which
> has a slightly unknown syntax. By comparison, the Icon method
> of lots of operators to scan across a string is seriously
> clunky.
There is truth here. For certain jobs, regexps are much terser and
and more expressive than Icon's string scanning. But then, on the
other hand, Icon's string scanning is much, much more powerful than
regexps. There would have been absolutely no sense in adding reg-
exps to the core language definition when they can only deal with a
small subset of the grammars scanning can handle.
It's just two very different approaches to language design. The
bottom line is that Icon is much more flexible, powerful, and ele-
gant for certain types of things. Perl is much terser, more lucid,
and more convenient for others.
>? Syntax. I don't agree that Perl syntax is ugly, at least no more
> than any other computer language.
What syntax? Perl was specifically designed to feel comfortable to
people accustomed to using a mishmash of sed, awk, sh, and C. There
has been some attempt at streamlining its grammar(s). But there is,
and never will be, any comparison between Icon and Perl along these
lines. Icon is just much, much cleaner.
>P Support.
The Icon community is small and "researchy." There's no comparing it
with the Perl community, which is just much larger and more responsive
to a larger range of questions and needs.
>>The input is a list of skills (C++, hardware repair, etc.),
>>structured as a three-level hierarchy (major category, minor
>>category, and skill name), with each skill followed by a list
>>of people who have that skill, and a rating of B for beginner,
>>I for intermediate, and E for expert.
>
>Hmm.. I'd give this project around 2-3 days in perl, at the most.
Bet it would take less time than this. But I don't see how Perl
would be any better than Icon here. The question is what language
you see as remaining workable over the long haul. Presumably this
isn't the last project you'll be doing!
--
Richard L. Goerwitz *** goer@midway.uchicago.edu